Section: Scientific Foundations

Software Components

Modules and services. The idea that building software components, i.e., composable prefabricated and parametrized software parts, was key to create an effective software industry was realized very early  [67] . At that time, the scope of a component was limited to a single procedure. In the seventies, the growing complexity of software made it necessary to consider a new level of structuring and programming and led to the notions of information hiding, modules, and module interconnection languages  [76] , [48] . Information hiding promotes a black-box model of program development whereby a module implementation, basically a collection of procedures, is strongly encapsulated behind an interface. This makes it possible to guarantee logical invariant properties of the data managed by the procedures and, more generally, makes modular reasoning possible. In a first step, it is possible to reason locally, about the consistency between the module implementation and the module interface. In a second step, it is possible to reason about composing modules by only considering their interfaces. Modern module systems also consider types as module elements and consider, typically static, modules as a unit of separate compilation, with the most sophisticated ones also supporting modules parametrized by modules  [65] .

In the context of today's Internet-based information society, components and modules have given rise to software services whose compositions are governed by explicit orchestration or choreography specifications that support notions of global properties of a service-oriented architecture. These horizontal compositions have, however, to be frequently adapted dynamically. Dynamic adaptations, in particular in the context of software evolution processes, often conflict with a black-box composition model either because of the need for invasive modifications, for instance, in order to optimize resource utilization or modifications to the vertical compositions implementing the high-level services.

Object-Oriented Programming. Classes and objects provide another kind of software component, which makes it necessary to distinguish between component types (classes) and component instances (objects). Indeed, unlike modules, objects can be created dynamically. Although it is also possible to talk about classes in terms of interfaces and implementations, the encapsulation provided by classes is not as strong as the one provided by modules. This is because, through the use of inheritance, object-oriented languages put the emphasis on incremental programming to the detriment of modular programming. This introduces a white-box model of software development and more flexibility is traded for safety as demonstrated by the fragile base class issue  [71] .

Architecture Description Languages. The advent of distributed applications made it necessary to consider more sophisticated connections between the various building blocks of a system. The software architecture  [79] of a software system describes the system as a composition of components and connectors, where the connectors capture the interaction protocols between the components  [39] . It also describes the rationale behind such a given architecture, linking the properties required from the system to its implementation. Architecture Description Languages (ADLs) are languages that support architecture-based development  [68] . A number of these languages make it possible to generate executable systems from architectural descriptions, provided implementations for the primitive components are available. However, guaranteeing that the implementation conforms to the architecture is an issue.